DietPi-Banner | Use Cloudflare worker on own domain for GeoIP #4798
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Removed adding the old one to Pi-hole whitelist: 04939bc |
+ CHANGELOG | DietPi-Globals: G_GET_WAN_IP: We use our own GEO IP service now to show the systems WAN IP and location in the DietPi banner and DietPi-VPN. When Pi-hole was used, with a previous update, "freegeoip.app" was added to Pi-hole's whitlist, which is now not required anymore. You may hence remove that entry from the whitelist.
|
should we remove PiHole whitelisting on next update? |
|
I added the hint to the changelog, but I think it is okay to not remove it automatically as it may be used manually. Probably a yes-no question whether to remove or keep it would be okay, if we can check whether it is on the list at all. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Status: Ready
Commit list/description:
This should once and for all solve those nasty blocklist issues as long as we take care that no unintended 3rd parties start to use it (in which case we may implement a user agent or headers based filter).
One change compared to the previous solution is that the country is shown with the two letter country code, e.g.
DEinstead ofGermany. There is no native Cloudflare workers API to get the long name. It is trivial to add additional fields to the response, e.g. we can achieve this via GET parameters in future DietPi versions, keeping the default<IP> [<region if available] <country>if no query string is passed, to keep backwards compatibility.Another thing: I'm not sure how the public APIs handle it, but in our case, AFAIK a proxy will lead to the proxy servers IP and location being shown, as we do not respect the proxy headers, just the Cloudflare request headers. But could be tested, probably Cloudflare itself overrides its client IP header with the proxy header, when present. I however think this is actually fine so that one can check whether a proxy is used as expected, similar to how the VPN server IP is shown when a VPN is used (in which case there is no original client header available, of course).